[ Mega Script
Archive ] [ Frequently
Asked Questions ]
- What does chmod xxx mean? What
is chmod?
- What platforms do your
scripts run on?
- Is there a charge for your
scripts?
- What does Server Error 403
"File Not Found" mean?
- What does Server Error 500
"Malformed Header From Script" mean?
- What does Server Error 501
"Cannot POST to non-script area..."
mean?
- What does "Internal Error:
execve() failed" mean?
- What is Unix? And what is A
Unix/System Prompt?
- What is a cgi-bin?
- Do I need a cgi-bin to run
these scripts?
- What is #!/usr/bin/perl
and do I need to modify it?
- I had the scripts mailed
and now they won't uncompress?
Short Answer:
Chmod is a Unix command which changes the
security settings for particular files,
giving users and groups permission to read,
write, and/or execute certain files.
Long Answer:
For many of my scripts, the uid (User ID)
that the web server is running under must
either execute (in the case of the perl
scripts) or write or read certain files.
There are several different cases in which
different chmod commands will be used. For
example, any of the perl scripts that must be
placed into the cgi bin, must also be
executable by the web server. This means you
must use:
chmod 755 filename.pl
This allows anyone to read and execute
your file and it allows you the permission to
write to it. Any of the files that are
automatically updated by perl scripts, must
be writable and readable by all, including
the web server uid. Unless you have super
user access, this means setting your files
to:
chmod 777 filename.[html|txt]
This will allow everyone to write to your
files. If you are still confused on this
matter, you must know that to use chmod you
must: 1) Have a unix account, 2) Be able to
telnet to that unix account or dial up into
the account, and 3) be able to use the shell.
If you do not have either of these, you will
need to ask your system administrator how you
can get around using chmod or what you need
to do in order to get it to work.
Form More Information: If you have
a Unix account you can type:
man chmod
or else you can get the man (Manual) pages
off of the web for chmod.
Short Answer:
They were created for Unix Systems that
have Perl installed on them.
Long Answer:
These scripts can be used on any platform.
They were specifically created for a unix
machine that has Perl installed and compiled
on it. These programs should work on Perl 4
and higher. Many users have told me that they
were able to port these scripts to Windows
and Mac, using the Windows and Mac ports of
Perl. A minimum amount of hacking was
required and it was mainly a fact of changing
around the date and doing small touch ups to
the scripts. If you have ported a scripts to
either Windows or Mac, please let me know and
send the source. I will gladly post it into
the Extras section of my scripts archive so
it will be available to everyone!
However, certain scripts, specifically the
HTTP Cookie Library, TextClock, TextCounter,
and some others should work without any
porting required because they lack any Unix
specific features.
Short Answer:
No.
Long Answer:
There is no charge for my scripts, however
it is expected and required that all
copyrights and headers remain in tact. If you
are setting up this script for others, you
should not charge them for the code, however
you are allowed to charge for your
installation, configuration and modification
time.
Short Answer:
The URL in one of your scripts that
pointed to a file was wrong. The file was not
found.
Long Answer:
Make sure that all of the URLS are correct
in the scripts and make sure that when the
necessary portions of certain URLS are
combined they form complete URLS. This isn't
one of the most common errors received when
setting up my scripts, but many do enter the
URLS wrong or do not change them from the
standard distribution.
Short Answer:
Something Went Wrong. Sorry, that's about
as specific I can be with a '500' Error. It
could be ALMOST ANYTHING.
Long Answer:
Error 500 could be ANYTHING! (almost).
Below is a mist of some of the most common
problems and how you can go about fixing
them.
- Check to make sure that the
ACTION="" of your script is
pointing to the correct CGI program.
If it is, make sure that this file is
also chmoded 755 so that everyone,
including the Web Server User ID has
permission to execute it.
- Check your server's error_log (On
NCSA servers, this will most likely
be located in
/usr/local/etc/httpd/logs/error_log).
Check them right after you receive
this error. They will often give you
insight as to why you received this
error. If there are problems with the
scripts, correct any that the
error_log may mention.
- Run the script from the shell and
make sure that you don't get any
errors.
- Make sure all files that supposed to
be opened during execution by the
script are chmoded so that the web
server can read them.
- Check all paths to certain commands
and make sure they are correct. An
incorrect path in your script will
cause execution of your script to
halt.
- Check your #!/usr/bin/perl
line and make sure that it points to
the proper location of the perl
binary on your system.
These are just a few of the MANY
possibilities. If you have solved this
problem in another way, let me know so I can
add it to this list. If you have done all of
this including reading the README file and
doing what it says to each script, feel free
to email me with your problem.
Short Answer:
You probably are not using a valid cgi-bin
or have not correctly renamed .pl files to
.cgi as is required on your system.
Long Answer:
There are two different ways that CGI
scripts are most commonly configured to run
on most systems. The first requires that
scripts must be placed in a valid cgi-bin for
them to work. Error 501 usually says that the
server does not support the method POST to a
non script area at this time. This means that
since you do not have your files in a server
defined cgi-bin, the server will not allow
the POST method to these files, and will not
execute these scripts.
Another solution is that your web provider
has turned on ExecCGI, allowing any file in
your directory with a .cgi extension to be
executed. Try renaming your .pl files to
.cgi.
More Information: If all else fails
and you are still getting this error, write
your system administrator and ask if you can
place these scripts in a cgi-bin directory or
if you can have permission to execute CGI
scripts.
Most likely the path to your Perl interpreter is
incorrect. This means that the line:
#!/usr/bin/perl
located at the top of your perl file, needs to be
changed to the correct path. This is often:
#!/usr/local/bin/perl
or
#!/usr/local/bin/perl5
If you absolutely can't find it, try using the
following command or mailing your system
administrator.
which perl
This will give you the location of the perl
program if it is in your path.
Short Answer:
Unix is an operating system that is one of
the most popular platforms for internet users
and web servers. As more and more people are
getting into the net more Macintosh and
Windows/DOS Environments will begin to enter
as well. Unix comes in many flavors,
including: HP-UX, SunOS, OSF/1, Linux, BSD,
and many more.
Long Answer:
All of these scripts were written and
tested on machines running BSDi. They have
been successfully installed by me on all of
those platforms with both the Apache and NCSA
servers. When I refer to Unix I am talking
about an operating system, just like DOS,
Macintosh (and arguably Windows). When I
refer to a system or unix prompt, I am
talking about your Korn Shell or C Shell, or
the many other shells out there. From there
you can execute such commands as chmod, mv,
cp, vi, and many other useful programs. These
scripts have also been set up on other
Platforms and Operating Systems.
Short Answer:
A cgi-bin is a special directory
designated in the config files of a web
server to allow execution of CGI scripts in
specified directories. Many new servers have
done away with this and allow users execute
any scripts ending in .cgi.
Long Answer:
The cgi-bin is used to help keep systems
secure. Keeping CGI scripts limited to
trusted users is necessary since CGI opens up
a lot of security risks. Therefore, most web
platforms allow only files inside of a
cgi-bin to be executed. This can be changed
and on many machines a .cgi extension has
been implemented to let anyone use CGI
scripts in their directory simply by changing
the filenames to have .cgi extension. If this
has not been enabled on your system and you
don't have a cgi-bin already, ask your system
administer if you can have access to execute
CGI scripts on your server.
Short Answer:
Yes.
Long Answer:
Yes and No. A cgi-bin is needed to run
these scripts unless your system
administrator has turned on ExecCGI, which
enables .cgi extensions to be used in any
directory. To find out if you can use CGI
scripts, your best bet is to ask your system
administrator if you can. He/She may opt to
give you a cgi-bin in your directory, turn on
ExecCGI or check your script and then place
it in the server cgi-bin. Either of these
options is ok for my scripts purposes. Just
make sure you set all variables to reflect
any changes you have to make to the location
of files and scripts.
Short Answer:
This line must be the first line in your
perl program source. It tells the shell that
is executing this script where the perl
binary is to use to run this program.
Long Answer:
This line must be in your perl script as
the first line to get it to run right. This
often causes a 500 Server Error if this is
not set as your first line or if it is set in
the wrong place. To find out the location of
your perl binary, type the following at your
unix prompt:
which perl
and copy the info it returns as the first
line of you program, with #! in
front of the location of perl. If this
command fails, ask your system administrator
if you have perl installed on the system and
where you should point this line to.
Short Answer:
You will need to first uudecode them and
then use the uncompression scheme you
specified.
Long Answer:
When the file comes to you in the mail, it
will be the script you requested in the
specified compression. The only difference in
the compression scheme is that these files
have been uuencoded so that they will easily
travel as text files through the mail. To
uudecode them, first save the file into your
unix directory into a filename like:
script.uue
Then quit out to your unix shell. Once you
are at your unix prompt, type:
uudecode script.uue
If uudecode was on your system, you can
now type ls and see a new file in
your directory. This should now have a
familiar extension on it and you can
uncompress it from there. In case you don't
know how to uncompress the file you got after
it was uudecoded, use the following steps:
.tar.gz
TYPE:
gunzip filename.tar.gz
tar -xvf filename.tar
.tar.Z
TYPE:
uncompress filename.tar.Z
tar -xvf filename.tar
.zip
TYPE:
unzip filename.zip
Those commands assume you are on a unix
machine and in your unix shell. There are
various other programs to uncompress files in
Windows and Macintosh environments.
[ Mega
Script Archive
]
|